I think this is right, so long as the allocator client is correct. To expand on that a bit, the concern is that invariant() could interleave some other sequence of (correct!) operations such that it observes front() being meaningful (that is, not the stub) and then, later, observes back being nullptr. The only things that can set back to nullptr are init() and destroy(), both of which only execute on the (singular) consumer thread and which should be gated by a global invariant: the consumer can only (re)initialize its message queue if all possible messages have already been received, in which case, there won't be any producer threads with which to interleave.

However, that neglects remote double-free. If a deallocating thread makes it as far as getting into

I think we will end up (at least in the Cornucopia prototypes and the eventual CHERI+MTE world) with double-free guards being rather towards the front, before we could even get to enqueue()ing to the remote queue. In the current stochastic detection regime, we're tripping an assert when we detect double-frees anyway, and we're much more likely to cause double-frees to trip over the intended "congratulations, you corrupted the message queue" assert(s) rather than this one.

I think we will end up (at least in the Cornucopia prototypes and the eventual CHERI+MTE world) with double-free guards being rather towards the front, before we could even get to enqueue()ing to the remote queue. In the current stochastic detection regime, we're tripping an assert when we detect double-frees anyway, and we're much more likely to cause double-frees to trip over the intended "congratulations, you corrupted the message queue" assert(s) rather than this one.

So this is a SNMALLOC_ASSERT not a SNMALLOC_CHECK, so is more for debugging the allocator rather than detecting user errors. I think the double free protection would catch issues much better than this assert.